A web service is a software vehicle that accepts requests from a client to perform operations. At this time, these requests are typically in the form of Extensible Markup Language (XML). Although XML is used as an example, other forms of invocation are also possible. In most cases, a web service returns a response after processing the request. This prior art architecture is illustrated in FIG. 1, which shows a web service client 100 submitting an XML request, as shown with arrow 102, to a web service 104. The web service 104 generates an XML response, as shown with 106.
Web services typically operate independently of a specific computer language, platform, or location. Therefore, a client can contact a web service that is written in a different programming language, which is running on a different platform, and is located across a network.
Because web services can contact each other to request the execution of operations, they serve as building blocks for distributed systems. Distributed systems composed of web services may span multiple machines, a corporate intranet, or the Internet. Combining web services from a base environment with web services outside the base environment, such as those operated by partners or suppliers, can create complex applications, such as shown in FIG. 2.
FIG. 2 illustrates a base environment 200 under common control, such as an intranet. The base environment 200 includes an order processing client 202, which accesses an order processing web service 204. In fulfilling an order, the order processing web service 204 accesses an inventory web service 206, which resides in the base environment 200 and a credit check web service 208, which is located in a first partner environment 210. The inventory web service 206 accesses a shipping web service 212 in a second partner environment 214.
FIG. 3 illustrates a prior art networked computer environment 300 that supports a distributed web service. The computer network 300 includes a client computer 302 connected to a communication link 304, which may be any wired or wireless communication link. Also connected to the communication link 304 are a first server 306 and a second server 308.
The client computer 302 includes a central processing unit (CPU) 310 connected to a bus 312. A network interface 314 is also connected to the bus 312. A memory 316 is also connected to the bus 312. The memory 316 stores web client software 312, which may be used to initiate a web service client request using known techniques.
The server 306 includes a network interface 320 connected to a CPU 324 via a bus 322. A memory 326 is also connected to the bus 322. The memory 326 stores individual executable programs in the form of web services 328A-328N. Server 308 also includes a network interface 330 connected to a CPU 334 via a bus 332. A memory 336 stores individual executable programs in the form of web services 338A-338N.
Using web services to integrate both internal and external data gives an organization flexibility. An organization can focus on creating applications for the business problems in a domain of expertise, and make use of the web services provided by other organizations in order to complete a business process. An organization can also offer its web services for use by other organizations.
Typical web service architectures are based on the following elements: a transport protocol, a message format protocol, a service definition language, and a mechanism to locate the web service. The function of each element is described below.
The transport protocol indicates how messages are sent to the web service. HTTP (Hypertext Transport Protocol) is the most popular transport protocol for web services, as it makes possible universal connectivity via the Internet. HTTP supports a request-response message pattern between a client and a web service. Other transport protocols can also be used for web service communication and for one-way communication (i.e., a request that does not require a corresponding response).
Messages between clients and web services may use SOAP (Simple Object Access Protocol). SOAP is a protocol specification that defines a uniform way of passing XML-encoded data. SOAP also defines a way to perform remote procedure calls using HTTP (or another transport protocol) as the underlying communication protocol. A client sends a SOAP request message to the web service, and receives a SOAP response message in return. Using SOAP, the service requestor and the service provider can communicate as long as they agree on a common transport protocol (such as HTTP) and the message's SOAP definition. This increases the opportunities for reuse, as the service places essentially no constraints on the platform, language, or location of its clients.
The web service's interface is defined in a Web Services Description Language (WSDL), which is an interface description language defined in XML. In order to announce its operations to potential clients, a web service provides a WSDL file that describes the service's network address, the list of operations, and the messages that it uses to communicate. If a client has access to the WSDL definition for a service and the proper security credentials, it can access the service with no additional information.
Web service clients typically locate a WSDL file using a published URL address. Currently, clients typically retrieve a WSDL file from a hard-coded URL location. Eventually, vendors will publish the URLs for their web services using UDDI (Universal Description, Discovery, and Integration). UDDI defines the interface to a repository that allows web service providers to advertise their services and allows clients to locate the web services they need.
The construction of distributed enterprise systems from web services raises management challenges. Although the independent language, platform, and location qualities of web services simplify the construction of distributed systems, these characteristics complicate the problems of monitoring, managing, and controlling these systems. The ability to combine these systems magnifies the management challenge.
Web service developers will typically spend their resources to implement business functionality rather than to implement system management facilities, such as security, logging, performance monitoring, and failover. While some implementers may incorporate system management facilities directly into their web services, different organizations may do so with incompatible infrastructures, thereby making it impossible to manage a distributed system in a consistent manner.
Since web service developers are not providing adequate system management tools, individual users must create such tools on an ad hoc basis. An organization utilizing a web service is generally focused on an underlying business that has nothing to do with the web service. Therefore, the web service is outside of the core competency of the business. Accordingly, hiring individuals to run and deploy the web service can be distracting and inefficient. There are various web service application platforms that are commercially available to make this process easier. Nevertheless, these web service application platforms still require recoding of the base web service in order to expand the functionality of the web service. This recoding operation can disrupt the successful operation of the base web service.
In view of the foregoing, it would be desirable to provide a mechanism for enhancing the functionality of existing web services. Ideally, the technique would provide enhanced functionality without disrupting the code associated with the underlying web service.